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Since the birth of software engineering, it always are recognized as one pure engineering subject, 
therefore, the foundational scientific problems are not paid much attention. This paper proposes 
that Requirements Analysis, the kernel process of software engineering, can be modeled based 
on the concept of "common knowledge". Such a model would make us understand the nature 
of this process. This paper utilizes the formal language as the tool to characterize the "common 
knowledge" -based Requirements Analysis model, and theoretically proves that : 1) the precondi- 
tion of success of software projects regardless of cost would be that the participants in a software 
project have fully known the requirement specification, if the participants do not understand the 
meaning of the other participants; 2) the precondition of success of software projects regardless 
of cost would be that the union set of knowledge of basic facts of the participants in a software 
project can fully cover the requirement specification, if the participants can always understand the 
meaning of the other participants. These two theorems may have potential meanings to propose 
new software engineering methodology. 

Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/ Specifica- 
tions — Methodologies; D.2.8 [Software Engineering]: Metrics — Software Science 

General Terms: Theory 

Additional Key Words and Phrases: Requirements Analysis, Common Knowledge, Formal Lan- 
guage, Theory of Software Engineering 



1. INTRODUCTION 

Since the birth of computer software engineering, it is regarded as a pure engineering 
subject. Among engineering practices, the manufacture industry is recognized as 
a classic and mature instance, therefore, the concepts in manufacture industry are 
widely imported into the field of software engineering. The production process 
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of computer software are argued to be similar to the production of a cup, a car 
or something else. But some obvious facts tells us, the production of software is 
certainly different to material production such as car, cup and so on. The most 
direct evidence is that: software crises often occur. Even if two softwares are very 
similar, the subsequence of software developments may totally differ. Some reports 
claim that high percent software projects are over budget, behind schedule, and 
unreliable. Moveover, some software productions do not gain high user satisfaction, 
even that are evaluated as impractical [Gibbs 1994]. 

Because software engineering is hardly regarded as scientific subject, some foun- 
dational theoretical problems are ignored deliberately or unconsciously, the research 
papers on the foundational principles are little published. This paper tries to model 
the processes of software development to understand the principles of software en- 
gineering, such that to provide some inspirations to the practices. 

In classical waterfall model, the full life-cycle of software development is divided 
as subsequent processes, i.e., requirements analysis, design, coding, test, deploy- 
ment and maintenance. Among all these processes, requirements analysis is the 
most important, and compared to requirements analysis, the other processes are 
quite technical, because the later processes can be more easily finished, even some 
scientists claim that they can be finished automatically, if the requirement speci- 
fication is fully, clearly and correctly defined; moreover, most failures of software 
projects would owe to the uncertainty of requirements. Therefore, we can focus on 
the nature of requirements analysis to explorer the principles of software engineer- 
ing. 

Requirements analysis actually is such a process that the demander and the 
team of developers achieve "common knowledge", that is, the demander knows 
what he/she wants to do, the team knows what the demander wants to do, and the 
demander knows the team knows what he/she wants to do, and so on. Based on 
this idea, we formally model the process of requirement analysis and theoretically 
prove two theorems: 1) the precondition of success of software projects regardless 
of cost would be that the participants in a software project have fully known the 
requirement specification, if the participants do not understand the meaning of the 
other participants; 2) the precondition of success of software projects regardless of 
cost would be that the union set of knowledge of the participants in a software 
project can fully cover the requirement specification, if the participants can always 
understand the meaning of the other participants. 

2. BASIC IDEAS 

For modeling the process of requirements analysis, we might as well discuss the 
common process of requirements analysis in the software industry. 

Assumed that the software development involves two persons or companies, we 
called them Side A and Side B, Side A has a demand to develop a software, and 
Side B will take the mission. Side B should communicate with Side A to know 
what Side A wants to do. During the communication, Side A and Side B would 
revise the specification or make the specification more clearly. Obviously, there is a 
final specification for every successful software project. So the aim of requirements 
analysis is to make Side A and Side B agree on the final specification. If we see 
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the final specification as a "prior" , then the aim of requirements analysis is to 
make the both sides understand the prior and agree on the prior. However, the 
subsequent problem would be: In what circumstance we can conclude that the 
project would succeed regardless of cost? As we know, the subsequent processes 
after requirements analysis would be quite technical, hence, the success of projects 
would seriously depend on the success of requirements analysis. Technically, if both 
sides understand and agree on the prior, the project would succeed regardless of 
cost. 

According to the ideas above, we say that if both sides have fully agreed on the 
final specification, then the project shall finally succeed regardless of cost. That is, 
if both sides achieve a common knowledge on the prior, the project shall succeed 
regardless of cost. This conclusion is based on the fact that if Side A knows every 
item in the prior, and Side B knows also, and Side A knows Side B knows, and Side 
B knows Side A knows, and Side A knows Side B knows Side A knows, and Side B 
knows Side A knows Side B knows,. . . , and so on, then if enough people force and 
materials are provided and enough time is given, the software shall be developed 
fully according to the final specification, and the product will be recognized by both 
Side A and Side B, that is, the project succeeds. 

The researches on "common knowledge" origin from the works of John C. Harsanyi, 
the 1994 Noble Prize winner and Robert J. Aumann, the 2005 Nobel Prize winner. 
This concept now has been applied into various of fields. Halpern and Moses re- 
searched the distributed systems by common knowledge and proved that knowledge 
can not be gained [Halpern and Moses 1990]. The work of K. Mani Chandy and 
Jayadev Misra advanced the conclusion above, and proved that knowledge can not 
be gained and can not be lost in a system which does not admit of simultaneous 
events, and theoretically proved that failure detection is impossible without using 
time-outs [Chandy and Misra 1986]. 

In this paper, we try to use the concept of "common knowledge" to characterize 
the process of requirements analysis, and furthermore, to discover some principles. 
Based on an intuition that if two persons have common language, they would have 
common knowledge, vice versa, we employ formal language to depict the new model. 
Of course, the intuition mentioned above can be easily extended to more than two 
persons. 

3. BACKGROUND OF MODELING 

For simplify, we only consider two sides: the demander and the team of software 
developers, and treat them as two agents. 

Every element in final specification or the "prior" can be regarded as a point, so 
the prior can be regarded as a point set, denoted as P. The point set of Side A is 
denoted as Pi, and that of Side B as P2. Every element in P is denoted as lower 
character. We call the elements as "basic facts" . 

The process of requirements analysis actually is a process of communication. All 
the content of communication would be a set, denoted as 0. 

We denote the languages of Side A and Side B as L\ and L 2 , and the initial 
states are Si and S2. 

The predicates of "knows" could be encoded into formal language. We use such 
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a code to represent it: if Side A knows the basic fact a, then a.l is an element of 
language of Side A. That is, a is the basic fact, the symbol "." is used as a separator 
and the symbol "1" represents Side A. Similarly, a. 2 means Side B knows a, a. 2.1 
means Side A knows Side B knows a. If we use a symbol "T" represents a. 2, then 
"T.l" means Side A knows T, i.e., Side A knows Side B knows a. 

Definition 3.1 common knowledge. For a given knowledge A, if every side knows 
A and every side knows every side knows A and every side knows every side knows 
every side knows A, etc., then we say, A is common knowledge. Formally, if 
.A(.[l|2])* G Li A i4(.[l|2])* G L 2 , then we say A is common knowledge. 

Definition 3.2 common knowledge of basic facts. For a given knowledge A, if A G 
P and every side knows A and every side knows every side knows A and every side 
knows every side knows every side knows A, etc., then we say, A is common knowl- 
edge. Formally, if A(.[l|2])* G L\ A A(.[l|2])* G L 2 , then we say A is common 
knowledge of basic facts. 

If without considering of the cost, then if Side A knows that Side B knows all 
that Side A knows and Side A knows all that Side B knows, Side A would "think" 
that Side B would perform the project well, but actually, when Pi C P after the 
full communication with Side B, Side A would make an error, because Side A does 
no have enough knowledge on the basic facts. Therefore, we give such a definition 
on success of project (without considering of the cost). 

Definition 3.3 Success of project regardless of the cost. If L\ = L 2 and Pi D P, 
then we say the project is successful regardless of the cost. 

We plan to model the process of requirements analysis with two models. One 
model is assumed that two agents have less intelligence, that is, they can't un- 
derstand any meaning come from the other agent, but only know the contents of 
messages, i.e., just considering the communication process. The other model is as- 
sumed that two agents have full intelligence, that is, they would understand the full 
meaning coming from the other agent. Obviously, human being would be stronger 
than that the first model says, and weaker than that the second model says. 

4. MODEL FOR COMMUNICATION 

For simplicity, we assume that the final specification has three points, and denoted 
them as a,b ,c. That is, P = {a,b,c}. 

So the language of Side A is L x =< C,T,S\,R >, ofSideBis L 2 =< C,T 1 S 2 ,R >, 
here 

T = PU{1,2}U{.} 
C = {M, N, V, U, Q} 
R is the rules set. 
There are two main rules: 

1. Knows himself. For Side A, there exists Si — > Si.l; For Side B, it is S 2 — > S 2 .2. 

2. Makes know. If Side A tells a message M to Side B, then we denote it as 
S 2 — > M.l; Correspondingly, if Side B tells a message N to Side A, then we denote 
it as Si N.2. 
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Therefore, 
R = { 
Si^QV 
S 2 QU 

V -> V.l 
[/ -> £7.2 
Q -> a|6|c 

V ->e 
U ->£ 

5 1 M.2V(M G L 2 ) 

5 2 N.1U(N G Li) 
} 

4.1 conditions of language equivalence 

We will illustrate the impact of rules by simple examples. 

If Pi — {a}, P 2 = {b}, then if rule 1 takes effects, then the language of Side A is 
L x = {a} U {a(.l)*}, and of Side B is L 2 = {b} U {b(.2)*}; When Rule 2 works, if 
Side A tells Side B the basic fact a, then the language of Side B will increase such 
sentences as a.l, a.l(.2)*; and when Side A tells a. 1.1 to Side B, then such sentences 
as o.l.l, a.l.l(.2)*, etc.. So the language of Side A would be {a} U {o.l(.[l|2])*} U 
{6.2(.[1|2])*} and the language of Side B would be {6}u{6.2(.[l|2])*}u{o.l(.[l|2])*}. 
Obviously, L x ± L 2 . That is, if Pi ^ P 2 , then L x ± L 2 . 

And then we consider that if Pi = L 2 . If Pi = {a}, P 2 = {a}, when Rule 1 and 
Rule 2 take affects, L x = {a(.[l|2])*}, and L 2 = {o(.[l|2])*}. That is, L x = L 2 . 

Actually, we can theoretically prove that the necessary and sufficient condition 
of language equivalence is Pi = P 2 . 

Proposition 4.1. The sufficient condition of language equivalence, if L\ = L 2 
then Pi = P 2 

Proof. According to Rule 1 and Rule 2, Li = {x.2(.[l|2])*|x e _P 2 }U{y(.[l|2])*|y e 
Pi}, L 2 = {y.l(.[l\2])*\y G Pi} U {x(.[l|2])*|a; G P 2 }; because L x = L 2 , therefore, 
{*.2(.[l|2])*|x G P 2 } C y(.[l\2])*\y G Pi, i.e., P 1 D P 2 ,{y.2(.[l\2])*\y G Pi} C 
{x(.[l\2})*\x £ P 2 },i.e.,P 2 D Pi. therefore, Pi = P 2 . □ 

Proposition 4.2. The necessary condition of language equivalence, if Pi = P 2 
then Li = L 2 

Proof. 1. Vx g Pi,x(.[l|2])* c L i; 
Li =x(.[l|2])*|a; £ Pi 

2. Va; £ P 2 ,x(.[l|2])* C L 2 ; 
L 2 =x{.[l\2])*\xeP 2 

3. because Pi = P 2 
therefore, L x = L 2 . □ 

When two sides communicate, how the knowledge transfer between them? Ac- 
tually, in this model, the common knowledge of basic facts can not be obtained 
and can not be lost. This means, the communication can increase the common 
knowledge of basic facts for both sides. 

ACM Journal Name, Vol. V, No. N, Month 20YY. 



116 • Bojin Zheng et al. 



Theorem 4.3. The common knowledge of basic facts can not be obtained. 
Theorem 4.4. The common knowledge of basic facts can not be lost. 
These two theorems are easy to prove. 
4.2 Application 

When applying the model to requirement analysis, we commonly care for the com- 
mon knowledge of basic facts. According to this model, we can say, unless the 
knowledge set of basic facts of both sides can cover the final specification, the 
project can not be guaranteed successful without considering of the cost. 

Theorem 4.5. If Pi D PandP 2 2 P, then L x = L 2 . 

PROOF. BecausePi D PandP D Pi therefore, Pi = P. 
Similarly^ = P- According to proposition 2,Li — L 2 . □ 

This theorem says that, when only considering the communication and excluding 
the understanding factor, only when Pi D P and P 2 D P, the project can succeed 
without considering of the cost. But for almost projects, P 2 2 P arc hardly possible, 
because Side B hardly knows the final specification before the communication. This 
theorem tells the difficulty of success of project. 

5. MODEL FOR FULLY UNDERSTANDING 

the language of Side A is L x =< C,T,Si,R >, of Side B is L 2 =< C, T,S 2 ,R >, 
here 

T = PU{1,2}U{.} 
C = {M, N, U, V, Q} 
There are two main rules: 

1. Knows himself. For Side A, there exists Si — > Si.l; For Side B, it is £2 -> 5*2.2. 

2. Understand. If Side A tells a message M to Side B, and Side B understands 
M,then we denote it as S 2 — > M.1,S 2 — > M; Correspondingly, If Side B tells 
a message to Side A, and Side A understands N, then we denote it as 5i ^> 

N.l,Si A N. 

Therefore, 
R = { 
Si^QV 
S 2 ^QU 

V -> V.l 
U -> 17.2 
Q -> a\b\c 

V -> £ 

U 

51 ^ M.2V(M e L 2 ) 

5 2 ^N.1U(N e Li) 

51 ^ MV(M e L 2 ) 

5 2 ^ NU(N G Li) 
} 
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Theorem 5.1. If Pi U P 2 2 P, then L 1 = L 2 . 

Proof. For any given x G Pi, according to rule 2,L 2 3 {x(.[l|2])*}; 
For any given y e P u L 2 D {y(.[l|2])*} ; 

Because Pi U P 2 2 P, therefore, for any given z £ P,{z(.[l|2])*} C L 2 ; 
Similarly, for any given z E P,{z(.[l\2])*} C Li; 
Because Pi U P 2 C P, therefore, L\ ~ L 2 . □ 

This theorem says that, even if the participants can fully understand the other, 
the success of project still are constrained to the knowledge of the participants. Lack 
of knowledge would lead to the failure. When the success depends on the integrity 
of knowledge, to add the knowledge, for examples, consulting to the proper experts, 
appealing to experienced engineers etc.. would be helpful to the success. 

This theorem can explain that some projects fail and other projects succeed, 
though the managers use the same strategy, to inflate the team . 

6. CONCLUSIONS AND FUTURE WORK 

As to software engineering, all people concede that it would be somehow art, partly 
because the scientific foundation is ignored. This paper tries to lay such a founda- 
tion by mathematic models. The two proposed models tell the borderline of success 
of project. At the best, this paper proves that, the software projects would fail if 
the knowledge of the software demander and software provider can't cover the final 
software specification , that is, lack of some knowledge, even if both sides have 
no any obstacle in the communication and can understand all the meanings of the 
other. 

In another words, we can say, outside of The Mythical Man-Month,not only the 
communication processes, but the lack of knowledge would contribute more to the 
unavoidable failure of software projects. This conclusion implies that software man- 
ager would pay more attention to the completeness of knowledge. 
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